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INTRODUCTION 

With llir advent uf iiit*x|M*n.“ivc terminals 
dial cunnnunirale directly with ;i general- 
purpose computer, there lias been a uoticea- 
1,1,. movement in the coinpiil injA industry lo- 
wni'ils utilizing tin* resources ol the com- 
putor in many new, non-inuneriiail applica- 
tions. For example, on-line creation and 
modification of programs and their docu- 
mentation have become widely accepted as 
productive and cost-effective uses of the 
computer. In fact, it has been realized that 
the facilities provided by a lime-sharing 
system’s central editing program and its 
command language are among the most im- 
portant determinants of the system’s con- 
venience, power, and consequent utility. 
Along the same lines, special-purpose com- 
puter-assisted text editing packages have 
become accepted in industry and govern- 
ment for the preparation or printing of 
technical manuals, proposals, and other 
documents in which many updates are nec- 
essary and revision time is at a premium. 
While 'these packages are primarily hai’il- 
copi/ output oriented, exciting research has 
been done, notably at the Stanford Ke- 
search Institute, on the ways in which dis- 
play console (soft-copy) oriented text- (and 
picture-) handling systems can enhance all 


aspect.' of the User's programming, writ in; 
and thinking. 

The purpose of this article is to siir\e\ 
various representative types of text niauip 
illation systems from the user's point u 
view, allowing him to see what lacilities ai'i 
available today. Implementation details o 
on-line systems, particularly with respect I, 
data structure manipulation, are covered n 
[17J. First, a general overview of a lypicn 
system is presented. Distinguishing charae 
(eristics of a representative sample ol sy- 
terns are then covered, using a Isomewha 
artificial I partitioning of these systems ini' 
the two classes ol “program editors ale 
‘•free-form text editors." The hardwan 
firmware editing features ol typical displu 
consoles are also hrietly discussed. 

Typical Structure of a Text Editor 

The simplified functional block diagrai 
in Figure 1 is representative of most editor, 
though the overall system in a pal'ticula 
case need not he segmented into the exm 
set of subprograms shown. The user i 
seated at a typewriter terminal or a call, 
ode-ray tube display console (('KTi n 
which one or more lines of characters of h 
file are visible. The terminal in effect pr, 
vides the user with a “window" on his fil 
The user’s commands to alter text display. 


('uliipiltin# Surveys, Yol. 3. No. 3, Sepleinbei 


9-1 


A mines van Dam and David Hire 


CONTENTS 


Introduction 93-1)7 
Typical Structure of a Text Editor 
Distinguishing Characteristics 
Program Editors 97-105 
Conversational Context-Directed Editor, II1M 
Cambridge Scientific Center 
Wyluuk, Stunfoid University 
Quick EDitor (QED), Coin-Sl. ire 
Text Editor und COrrector Cl ECO), MIT 
Tvedit, Stanford University 
Interactive Programming Support System, System 
Development Corporation 
Emily, Argonne National Laboratory 
Free Form Text Editors 105 111 
Magnetic Tape Selectrir Typewriter (MTST), HEM 
Corporation, and Authotype, Information Control 
Systems 

8ystern/360 Administrative Terminal System, IliM 
Corporation, and VIPcom, VIP Systems 
A Tublet-Hased Editor, Carnegie-Mellon Unis. i»ity 
The Hypertext Editing System (Hes) and File 
Retrieval and Editing SyStem (Fkess), Hrown 
University 

NLS, Augmented Human Intellect Research Center, 
Stanford Research Institute 
Editing Features of Typical Terminals 111 113 
Conclusion 113 
Postscript 113-114 
References 114 


Copyright (5) 1971, Association for Computing Ma- 
chinery, Inc. General permission to republish, but. 
not for profit, all or part of this material is granted, 
provided that reference is made to this publication, 
to its date of issue, and to the fact that reprinting 
privileges were granted by permission of the Asso- 
ciation for Computing Machinery. 


in (he window arc entered via tile type- 
writer keyboard (or Innelion keys, lightpen, 
or other input devices), while the physical./ 
logical attention (interrupt) generated 
when he transmits a command is iielded hy 
the Input Handler to a Command Inter- 
preter. This routine parses the requested 
command, typically into an editing opera- 
tion (insert, delete, substitute, rearrange, 
etc.) and assoeiated dala. The latter consists 
primarily of positioning information (e.g., 
at what point in the text an insertion is to 
he made, or between what two points in the 
text a deletion is to lie made I and literal 
diameter string data (e.g., the text to he 
inserted). In addition to editing, the user 
may “travel" through the text in order ei- 
ther to read or to make changes in a differ- 
ent section. The command in this case 
might he to advance the display window in 
the file, and the associat'd data field would 
indicate the number of display lines to lie 
advanced (“scrolled" ) and the direction 
(forwards or backward i . 

The parsed (internal i form of the request 
is passed to an appropriate editing or trav- 
eling routine that performs the actual oper- 
ation. Tile internal form of the text (alter- 
natively called tile data or storage struc- 
ture*) is altered (in the ease of an edit), and 
tlie updated text is reformatted hy the Dis- 
play Generator for feedback to the user. 
When tiie files are large, and traveling or 
large edits are invoked, the relevant, portion 
of tlie storage structure may not lie resident 
in core, in which case the Paging Routines 
must lie called upon to replace some inactive 
data in core with the data requested from 
secondary storage [6]. 

In tlie general case, tlie system supports 
multiple terminals, and a time-sharing 
monitor/file-handler is superimposed on tlie 
block diagram. It lias basic responsibility 
for supervising tlie sharing of programs and 
core among users while guaranteeing the 
integrity of their files. It may also provide 
other services, such as user-to-user messag- 
ing or even file sharing for cooperative ef- 
forts. 

* More precisely, the machine-independent struc- 
ture of the file may be referred to as the data struc- 
ture, while its machine-dependent encoding would 
lie the storage structure. 
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The llard-Copy Formatter (which may 
in fact lie largely merged with tlie Display 
Generator) is used in t he case of free- form 
text, (as opposed to program text ) to convert 
the storage structure of the file to conven- 
tional hard copy for output on typewriter 
terminals, highspeed line printers, or even 
photo-coinposition devices. In his text, tlie 
user may specify “format codes” (typeset- 
ting codes) that determine margins, head- 
ings, running heads, paragraphs, left and/or 
right margin justification, indents, center- 
ing, underscores, type-face changes, etc. 
These codes are frequently stored in-line 
with the text itself and may be treated as 
indistinguishable from text for editing pur- 
poses. Sophisticated formatters may pro- 
duce other byproducts useful for hard copy: 
foot-notes, hyphenation, tallies of contents, 
lists of figures, indexes, spelling checks, etc. 
Very readable accounts of the recent ad- 
vances in computer-assisted typesetting and 
printing are contained in [1 1] and [25]. 

The generic design goals of on-line edi- 
tors, from tlie user’s point of view, are: 


1 ) fast response to a large number of tmui 
mils (which ideally are designed will 
good “human factors" for the editiiij 
task) ; 

2) a concise, mnemonic command language 
with informative feedback; 

31 powerful commands, with few rcstric 
tions and exceptions, to make possibh 
anything that one can do to hard cop;, 
with pencil, scissors, and staples, or any 
tiling that one can do to program ear. 
decks; and 

4) commands that take advantage of com 
puter capabilities; e.g., traveling to t in 
first occurrence of a user-specified patten 
in the file (called pattern, content, or con 
text scanning) ; “uniform” substitution oi 
one pattern for another every place ii 
occurs, or only in the first instance, oi 
only if the pattern occurs in a ccrtaii 
column-dependent field; automatic re 
numbering of sections or references al’tei 
the file is altered; and flexible hard-copi 
output. 

Naturally, all of these goals are to he met 
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using as little as possible of such resources 
as money, implementation time, CPU cy- 
cles, core and disk space, etc. Furthermore, 
the goals arc both interdependent and con- 
flicting since, for example, increased power 
in the instruction repertoire implies greater 
demand on resources and therefore slower 
response time (or support of fewer termi- 
nals). 

Distinguishing Characteristics 

The storage method (the data/storage 
structure employed) and the editing func- 
tions provided by a given system are 
strongly influenced by the type of text upon 
which the system is intended to operate: 
computer programs are typically manipu- 
lated with “program editors” while ordi- 
nary manuscripts are edited with "text edi- 
tors.” On the other hand, the manner in 
which the editing functions are actually 
specified and the way text is displayed de- 
pend primarily on the type of terminal 
used, either a teletype/typewriter terminal 
or a CRT display. 

The first of the distinguishing character- 
istics between editors, then, is in the type of 
editing to be performed and the attendant 
structure of the file. When editing a pro- 
gram, one typically modifies the program 
“in place,” substituting one small string of 
text, such as an op-code or an operand ad- 
dress, for another, or inserting a label in a 
field (a portion of the line) that was pre- 
viously blank. In such cases it is quite rea- 
sonable to store the text line by line (80 or 
132 columns/ line i in card image or printer 
line image format. With an editor oriented 
towards free- form text, on the other hand, 
one wants to make insertions and substitu- 
tions of arbitrarily sized character strings 
at arbitrary points in the manuscript. This 
increased flexibility implies that the data/ 
storage structure should be more flexible to 
cope with the more powerful types of inser- 
tions and deletions (e.g., overflowing or con- 
tracting automatically from line to line, 
within a paragraph). Thus, one typically 
finds that the unit of storage within which 
text may grow or shrink dynamically is a 
“super” line or statement of several 
hundred characters, a paragraph, or even an 
emire “page.” 
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In both program and text editors, it. is 
possible to view the tile as more than a col- 
lection of lines or literal character strings. 
For example, it is useful to be able to 
present the block structure of a procedural- 
language program or the outline hierarchy 
of a sect inn-nninbered text by suitable for- 
mat ling i line skips and identation I on a 
display screen (see the sections on Kniily 
anti NLSl. Naturally, this block structure 
must be encoded in the data si rueturc. 

While it is entirely possible (and in fact, 
finite common l in use a given editor for 
either text or program editing, the design 
objectives and the resultant capabilities are 
usually specialized and more convenient for 
one than the other. tTlie NFS system [ l J] in 
which the editing system and language proc- 
essors were designed together to lorm an 
integrated system is a striking exception.) 
A rough classification of existing editors 
along these lines of specialization is there- 
fore possible. 

A second distinction is in the method- of 
specifying operations; this is primarily 
based on the type of terminal employed. 
Any editing task requires two inputs to 
the computer: the task to be done and 
identification of the portion of text to 
which it applies. If a teletypewriter is the 
input device, the task to be done is supplied 
by typing the name (or an abbreviation I of 
the command. The location in the text to 
which the command applies is identified by 
giving a line number, by typing tin appro- 
priate context string, or both. In most sys- 
tems using them, line numbers are defined 
as the displacements of lines relative to the 
top of the file; they are therefore rather arbi- 
trary since they can change dynamically 
as the file is changed, and in any case they 
hear little relationship to the actual text. 
With context identification, a user-specified 
string of characters (text I is searched for 
in the text to locate the desired position. 
Having to specify context often requires ex- 
tra work for the user since he must type 
enough characters to identify the location 
uniquely; otherwise unintentional ambigui- 
ties might be introduced. However, t he char- 
acter strings in the file are not subject to 
change by the system (as relative line num- 
bers are) and consequently context identifi- 


cation typically provides a inure stable 
method ol locating portions nl a tile. 

When a (’Ur display unit is used with 
some mechanism for pointing at the desired 
location, two improvements in location 
identification are made: text is rapidly dis- 
played and identification can lie made by 
"pointing.'' The pointing can be done either 
directly, as with a ligbtpen or a dala-lablel 
stylus, or indirectly, by overlaying the re- 
quisite character with a pointer symbol or 
"cursor" driven by keys (up, down, left, 
right I. a “joystick," or a "mouse" la hand- 
held A -Y transducer usable on any Hat 
surface I . Thus, teletypewriters require the 
user to locate the text in question explicitly, 
while CUT displays usually allow the user 
to point, relegating to the editing system 
the task of correlating the indicated point 
on the screen with the corresponding posi- 
tion in the internal data structure (typi- 
cally via "a correlation map"l. 

A third distinction pertains to the manner 
in which the text, is presented. Typewriter- 
like devices must print, (display) text me- 
chanically and are therefore excruciatingly 
slow (approximately 100-300 words/min- 
ute). As a result, the amount, of text that 
may be displayed at one time for edit- 
ing purposes is quite small (usually only 
one line). The tremendous advantage in 
using a CRT display is that the text is 
"printed” at electronic speeds, thus allowing 
many lines to be displayed at each stage of 
the editing process. Typewriter-like devices 
are so slow that they force the user to work 
from a mocked-up printed copy, manually 
transcribing changes already made in the 
printed copy, and therefore doing the work 
twice. With a CUT display, the editor may 
think out. and implement, his changes simul- 
taneously. Naturally, teletypewriter-equiv- 
alent CRTs that are connected over the 
same bandwidth line as a teletypewriter 
offer only the advantage of silent operation, 
at the disadvantage of not producing a 
hard-copy transcript of the session. 

The fourth distinction is in the functions 
for producing output and the form of the 
output. In a program editor, the text is dis- 
played and printed as it is stored, line by 
line. The only output facilities required are 
a “new line” function and possibly a tab- 
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long facility; only upper case charnel, 
need be used. In contrast, mo.-t text edin 
consider the displayed line and the piin; 
line as two distinct, temporary units to 
derived from the internal data siriictu 
The displayed lines tuny be simple inn 
pings of the internal form, showing, for , 
ample, only skipped lines and paraglnpl 
while the printed Version nitty be siiitai 
structured by arbitrarily complex types, 
ting codes. 


PROGRAM EDITORS 

Computer program editors have become i 
creasingly popular in time-sharing en\ ir, 
tnenls, where a facility for the on-line ua, 
ideation of programs combined with sm 
form of remote job entry lexecutio, 
greatly increases a programmer's product! 
ity. Immediate verification of correct s\ 
tax of the program is occasionally provid. 

The most common method for editing 
program in a non-time-sharing environm, 
is still to insert and delete cards from 
punched source deck, which then has to 
read back into the computer through I 
card reader. The dropping or loss of do, 
evokes bitter memories for till programme, 
Also, backspacing over typographical err,, 
with a keypunch is not recommended. . 
on-line editing system that stores the pi 
grains on disk or tape eliminates the tie 
for hand-carrying card decks to and fro 
the machine, and enables updates to 
made quickly and eiiieiently. When used 
conjunction with a time-sharing sysl, 
under which the source program can 
readily compiled, the time required to wt 
and debug a program is greatly reduced. 

Since many users have (potential) ace, 
to program editors, it was felt by the a 
tliors that actual examples of the use 
various system features would be desirabl 
simple transcripts are therefore provid, 
below for a few of the most common e, 
tors. 

Conversational Context-Directed Editor, 

IBM Cambridge Scientific Center 

A fairly typical program editor is t: 
Conversational Context-Directed Edit 
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developed at the IBM Cambridge Scientific 
Center for the 360 67 CP/CMS operating 
system ami known inure widely as the CMS 
editor [5], Its facilities, like tlio»e of most 
program editors, may be traced to the 
trendsetting context editor developed in the 
early 1960s for project Mao’s CTSS time- 
sharing system for the IBM 7090. Although 
the CMS editor is often used to edit normal 
text, the editing commands and the interac- 
tive terminals (IBM 2741s) are best suited 
for the simplified text of a computer pro- 
gram. 

The way that the text is stored internally 
depends on the type of text being edited. 
I'he text of computer programs is divided 
into fixed-length (80-character) records, 
corresponding one-for-one with a standard 
card deck of source code. This one-for-one 
storage scheme is the easiest to implement 
but is certainly not the must compact form 
of storage because most of a record (card) 
is normally left blank. Files of normal text 
(filetype Script) are stored as variable- 
length records (one line/record, with a maxi- 
mum of 130 characters per record (.thus pro- 
viding for a substantial savings in the disk 
space required to store a large on-line data 
base. When the text is in main memory, how- 
ever, the lines are treated as fixed in length 
and padded to 130 characters with blanks. 

Since the editor was written for a com- 
puter with virtual memory, the entire file 
currently being edited is kept core-resident, 
with individual lines connected in a two- 
way linked list structure for ease of travel- 
ing and multi-line editing. The primary ad- 
vantage of the virtual memory technique is 
that no programmed I/O to secondary stor- 
age is done by the editing program while 
the user is editing a file, and as a result 
response times are normally quite good. Of 
course, hardware paging to auxiliary mem- 
ory is done by the operating system [6], The 
risk in keeping an entire file core-resident is 
that if the machine or operating system 
should fail as the user is editing, all his 
work since he last saved the current file on 
disk is lost. In addition, the memory size of 
the virtual machine determines the maxi- 
mum size of a file. 

The CMS editor provides two modes for 
program modification. In the “input” mode, 


new text is continually enteivd, one line at 
a time. This inode is used to create a pro- 
gram or to insert several contiguous lines of 
code into an existing program. In the "edit” 
mode, text can be inserted by line, one or 
inure lines may be deleted, and a single line 
may be retyped. Changes within a line are 
made by typing the incorrect characters 
billowed by the replacement string; inserts 
are made by replacing the character string 
immediately in trout, of the insert point bv 
a string consisting of this context, and the 
string to be inserted, while deletes are done 
by a null replacement for the string to be 
deleted, 'l’his method for specifying editing 
changes is referred to as runlext-ilirccled 
editing. For example, to change DRANG FS 
to GRAPEFRUITS in the line: 

SUM = A FBI, MS + D RANGES 
the user would type: 

change /oranges, 'grapefruits./ 

As the previous example indicates, replace- 
ments within a line need not be of the same 
length; however, if the line length exceeds 
the maximum length for the particular type 
of file, the extra characters are truncated. 
Thus a large insertion in the middle of a 
line must be broken into separate lines to 
avoid this overflow problem. This restric- 
tion is not serious for program editing but is 
often very distracting for general-purpose 
editing. Universal replacements of one 
phrase for another within a file (such as 
changing a label and all of its references) 
can be done quite easily with the “change” 
command. 

Since the CMS editor is line-oriented, the 
current line in the program is determined 
by a “line pointer” that changes as travel- 
ing and editing occur. The current line is 
defined as that line being created or edited 
in the file at a given moment. The line 
pointer may be moved backwards or for- 
wards by one or more lines I following the 
backwards or forwards pointer chain) to 
accomplish scrolling through the file. There 
are also two useful commands that search 
for a specified character string occurring ei- 
ther in a fixed line position (“find”) or any- 
where in a line (“locate”). If a match is 
found, the line pointer is moved to the line 
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located, lienee, it a eharacier string that 
the user specifies while looking at formatted 
(justified) hard copy happens to he spread 
over two internal lines, it will not be found. 
Obviously, this situation only arises for 
text, and not for program editing. 

As an example of how a line-oriented 
program editor might lie Used, assume that 
the following section of a program, which 
computes the sum of two matrices, is to be 
modified to compute the difference of the 
two matrices: 

Villi loll How - I in N l»'. 

loll rol.l M.N I In M Ft 

C ilioU io|l\|\> \ |:o\\ ii'IJ \|\. i l> illott. tol.l MNj 

I .Mi 

i.nh 

'File following sequence of interactions with 
the editor would provide the necessary 
changes (the user’s requests are in lower 
case and the machine responses are in capi- 
tals! ; 

Imd add 

ADI). Foil KUW - I TO N Do, 
cliiuigr add 'subtract ' 

SUBTRACT- loll UOW - I To N Do, 

emow. column) - a mow. uu.i ,mni t i< mow, column; 
Uuu.g. i , t . - Aiicn\v,nii.rMX) • huiow, mu mni 

change •' ai|«l. subtract ' * * 

The routine ADI) is first located by using 
the “find” command, which searches for the 
string ADD beginning in the first, position 
of the fine. Next, the label ADD is changed 
to SUBTRACT. (The slashes (/) arc used 
as delimiters and can be any character not 
occurring in either the old or new strings.) 
Next, the fine pointer is moved ahead two 
lines by the command “next 2” to locate the 
next line to he changed; then the addition 
( + ) is changed to subtraction ( — ). The re- 
maining two commands search the entire 
program (starting at the “top”) to uni- 
formly replace all occurrences of ADD with 
SUBTRACT, so that any references to the 
ADD routine now refer to SUBTRACT. 

The CMS editor also provides flexible 
tabbing facilities that require less typing 
for the user when column-dependent lan- 
guages such as Fortran are being used. A 
tabbing facility also makes the programmer 
more likely to indicate block structures and 
nesting levels by suitable indentations, a 
useful documentation technique. Default 
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I internal! tab settings appropriate to tic 
specific language are automatically applh" 
to the file. For example, if the program Wei. 
being written in Fukiha.v the tab stop 
would be til position.- 7, It), Id. ”1), 2d, an 
30. 

Wylbur, Stanford University 

W vi.ltl K is :t line-oriented text editor de 
veloped by the Stanford Compulation Cin 
ter for use on 2741 terminal.- to provide a i 
on-line editing facility that i.- u.-ed in eon 
junction with the on-line and batch sendee, 
of Stanford's IBM 360 67 [20|. 

A W'yt.uiTt file is divided into lines o, 
text, each containing from I) to 133 charae 
let's; but normally a maximum of 72 charae 
let's is tiseil for programs. Fvcry line t 
stored as an unpadded character string with 
an associated length and fine number. Tim 
seems to be a more reasonable data strut- 
lure for the storage of computer program.-, 
which usually leave most of a fine (cardi 
blank. Text is still fine addressable, but tin 
storage is more compact. The fine number, 
are absolute (as opposed to relative to tin 
top of the file) and do not, change dynaini 
rally as editing is performed; this provides 
stable reference points. 

Wyliiur editing commands generally op 
crate on a ramjc of lines. A range is defined 
as a group of lines that all possess the same 
distinguishing characteristic. Ranges can be 
specified in several ways. An explicit range 
can be either all lines whose line number.- 
full within a given range, such as lines 3 
through 12 (indicated as 3/12), or simply a 
fist of fine numbers, such as fines 7, 12, and 
16.5 (indicated as 7, 12, 1 li.fi) . Both types 
of explicit, ranges may be combined so that 
“5, 9.1, 13.02/14.5, 20" would indicate lines 
5, 9.1, 20, and 13.02 through 14.5. The sec- 
ond type of range is the unsocial i i’c range, 
which includes all lines containing a given 
st ring of characlers, e.g., all fines containing 
the string “COMPUTER.” Fxplicit. and as- 
sociative ranges can also he combined: 
“COMPUTER” IN 6/12 would indicate the 
range of all lines between lines 6 and 12 
containing the string COMPUTER. 

The interline editing commands DE- 
LETE, MOVE, and COPY all operate on 
ranges of lines so that, for example, all lines 
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between (i and 12 containing the string 
COMPUTER can be deleted with one edit- 
ing command. 

Intraline editing is done with the MOD- 
IFY command. The line to be modified is 
typed at the terminal, and the user indi- 
cates changes by typing special characters 
under the typed line. For example, he can 
delete part of the line by typing a “D" 
under the first and last characters of the 
string to be deleted; he can insert a string 
into a line by typing an ‘Y” under the char- 
acter before which the insert is to go, fol- 
lowed by the character string to be inserted 
.total length not to exceed the maximum 
line length of the file) ; and he can replace a 
same-length string by typing an ''It” fol- 
lowed by the replacement characters. Re- 
placing strings of different lengths can be 
done using the “D" and “I” forms. 

Uniform changes can also be made to a 
range of lines using the CHANGE com- 
mand; for example: 

CHANGE “ADD” TO “SUBTRACT" IN Abb 

changes the string ADD to SUBTRACT 
everywhere it occurs in the file. The key- 
word ALL specifies the range of all lines in 
the file. 

In addition to the editing facilities of- 
fered, Wylbur provides a complete group of 
commands for sending programs to the 
batch processor to be assembled or com- 
piled, and for listing the current, status of a 
job in progress. 

Quick EDitor (QED), Com-Share 

One of the best known examples of a tele- 
type-based program editor utilizing varia- 
ble length lines is the Quick EDitor (QED) 
developed originally by the University of 
California at Berkeley and revised exten- 
sively for commercial use by Com-Share [7, 
15]. It was designed expressly to provide 
maximum convenience for the user via a 
simple and mnemonic command language 
and line-independent access to the text. 

QED is internally superline oriented. 
However, text is not stored as a fixed length 
record or a variable length record with an 
associated length. Instead, the end of the line 
is delimited by an internal marker. A line 
can be up to 500 characters long, although 


only 80 are printed per teletype-line li.c., it 
prints 80 character lines until it has ex- 
hausted the 500 characters. 

QED has provisions for content address- 
ing similar to those of the CMS Editor, 
providing a natural means of locating sec- 
tions of text. QED can search for a preas- 
signed label beginning in the first position 
of a line, or for an arbitrary string any- 
where in the text. 

The editing commands include insert 
(one or more complete lines’), delete (one or 
more complete lines), change (i.e., replace 
one or more complete lines), and substitute 
(replace only part of a line; this is not re- 
stricted to one-for-one character replace- 
ments but the replacement must be less 
than the teletype line). In addition, there 
are control characters that are used to 
make more complex (but still minor) edit- 
ing changes within a line. 

An example of a simple QED editing se- 
quence is: 

*7 INSERT 

100 DO 101 I = 1,N(CS) 

101 SUM (I I =A (I) + B(l) <SD> 

This sequence inputs two lines into a 
Fortran program preceding the 7th line in 
the buffer. The asterisk is typed by QED to 
indicate its readiness for a new command. 
Lines are ended with the carriage return 
symbol(CR), a nd th e insert is ended with the 
special symhol(DQ). A more powerful exam- 
ple is: 

*4,10;/ADD/SUBTRACT/(6r) 

which changes the string ADD to SUB- 
TRACT each time it is found in lines 4 
through 10. 

An interesting feature of QED is that a 
sequence of editing operations can be saved 
by the system as a normal text file. At a 
later time, this set. of commands can be re- 
executed (after possible modification of the 
commands) to re-edit the text. Of course, if 
the original text, file has since been modified, 
the editing commands may no longer be de- 
fined. The re-editing facility makes it possi- 
ble to maintain slightly different versions of 
a file without having to duplicate the main 


file many times. The text is stored only 
once; the alternate versions are described 
by additional short files that contain only 
the appropriate editing changes. This is 
useful for testing changes to an operational 
program without actually modifying the 
original program until the changes have been 
checked out. 

Text Editor and Corrector (TECO), MIT 

Another well known program editor for 
teletypes is TECO, developed by the Mas- 
sachusetts Institute of Technology and Pro- 
ject Mac for Digital Equipment Corpora- 
tion's PDP series of computers [20]. It is 
commercially available from Interactive 
Sciences Corporation on the PDP-IO. 

TECO editing commands tire more primi- 
tive than QED’s; however, the fundamental 
set of commands is used its a set of building 
blocks that may be combined to provide 
finite elaborate editing operations. The 
drawback is that the user must think on it 
level lower than Unit required by other sys- 
tems, and frequently must construct a little 
“program" of the basic commands to per- 
form the edit. Among the fundamental com- 
mands are insert, delete, context scanning, 
and conditional execution. 

Unlike the previous editors, TECO is not 
line oriented. A file is a sequence, of charac- 
ters, normally broken into variable length 
“pages” by Form Feed characters (which 
cause page ejection in hard-copy printout). 
Pages may be combined in an in-core 
“buffer,” but normally one page at a lime 
is edited in this buffer. After a buffer has 
been edited, it is written sequentially onto 
a second file, and the next page is accessed 
from the original file (or a different one). 
Because of this sequential organization, 
backing up to a previous page is not per- 
mitted; one must re-read the newly created 
file from the beginning. 

The current position in the in-core buffer 
(displacement, into the buffer) is deter- 
mined by a character pointer that points 
between characters. This pointer can be po- 
sitioned absolutely (by a numeric value), 
relatively (by a positive or negative char- 
acter or line displacement), or by pattern 
searches. “Q registers” are available both 
for doing arithmetic and for moving or 


copying strings of text. If a Q register cun 
tains text, the text may be interpreted as •• 
command string (a macro facility). T, 
move a string of text, for example, tin 
string would first be saved in a Q-regislei 
and then deleted from the buffer. Next, tic 
character pointer would be moved to a ne\ 
location and the contents of the Q-registe, 
copied into the buffer at this new point. 

As an example of "bootstrapped'’ com 
mauds, consider the schematic diagram of ; 
program that substitutes "string2” fi 
"stringl" uniformly in a file (see Figure 2i 
Whenever a context pattern I “stringl”) i 
found, the character pointer (called R ii 
Figure 2) is automatically positioned aft e. 



Fig. 2. Schematic representation of a universe 
substitute in TECO. 
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i lie last character of the pattern. The length 
.if “stringl” in Figure 2 is “N.” 

To uniformly substitute “grapefruits” for 
"oranges” wherever “oranges” occurs, one 
specifies the program: 

J < SO R A N G K SS ; — 7 1 ) I G 1 1 A l 1 1'T RUITSS > 

"J” denotes jump character pointer to the 
left of the first character in the huffer; “<” 
and “>” denote the scope of commands in 
i he iteration; “S” denotes search for the 
pattern that immediately follows (OR- 
ANGES) and is ended by the “8,” position- 
ing the character pointer to the right of the 
last character in the string (i.e., to the right 
of the matched “S”) ; “ ;” delimits the com- 
mands to be skipped in case of a scan fail- 
ure, so that the next command to he exe- 
cuted is the one following the matching 
■ >”; 7D” denotes the deletion of the 7 

characters to the left of the pointer, again 
leaving the pointer to the left of the charac- 
ter immediately following the “S" of the 
deleted “ORANGES”; “I” denotes insertion 
to the left of the pointer of the string imme- 
diately following (GRAPEFRUITS), up to 
the 

Tvedit, Stanford University 

Tvedit is one of the earliest (1965) 
time-sharing, CRT-based text editors [12, 
22]; it displays many lines of text at elec- 
tronic speed. The user thus continually 
views the most recent version of his text 
and does not have to constantly refer to a 
mocked-up copy. Users ordinarily create 
and maintain text without any hard copy, 
not even an initial hand-written draft. 

Because of careful user engineering, the 
simple Tvedit command language is almost 
invisible to the experienced user. A control 
shift button alters the interpretation of al- 
phanumeric keys to perform required func- 
tions. A request for these functions can be 
preceded by a number to repeat the com- 
mand that number of times. Commands are 
executed as they are typed, so the user 
never has to press an execute command key 
and is seldom forced to wait for a system 
response. 

Line-oriented editing is performed by us- 
ing a pointer displayed on the screen. The 


pointer can point al either a line or between 
two characters and can he moved by typing 
spare, backspace, and carriage return with 
tlic control shift down. Control carriage re- 
turn moves the pointer to the next line. 
Control/space moves the pointer to the next 
character or to the first character in the line 
if the pointer pointed at a line. Control/ 
backspace moves the pointer hack one char- 
acter or line depending on which of these is 
indicated by the pointer. Note that these key 
combinations simulate the cursor control 
keys on alphanumeric editing consoles dis- 
cussed in the section on editing features ol 
typical terminals. 

Characters can he replaced by simply 
typing the replacement over the old charac- 
ters. Lines or characters are deleted by 
moving the pointer to just before the item 
and typing a control character. When delet- 
ing single characters, characters to the right 
of the deletion on the line move to the left 
so the pointer uppeura to “swallow” charac- 
ters. Similarly, for insertions, the characters 
to the right of the pointer move to the right. 
Since only 50 characters can he displayed 
per line anil lines can he up to 128 charac- 
ters, lines longer than fifty characters will 
appear to he truncated on the display. A 
symbol appears to indicate this truncation. 

To facilitate travel, the user may seg- 
ment the text into “pages" by inserting 
page marks between any two lines of text. 
The travel commands are: go to the next 
page, go to the nth page, and display the 
next screenful of text. The system can dis- 
play text almost as fast as the user can type 
the one-key command. As a result, users 
usually find text by requesting the approxi- 
mate page and visually scanning forward to 
the desired view. No explicit pattern scan- 
ning commands are provided by the editor. 

Interactive Programming Support System, 
System Development Corporation 

This editor [2] has been designed for the 
IBM 2260 alphanumeric CRT display unit, 
making maximum use of its limited capa- 
bilities. The 2260 has a cursor (a “typing 
pointer”) that may be driven around the 
screen, but does not have a user-held point- 
ing device. As currently implemented, the 


editor is used to create and edit programs 
written in a procedure-oriented program- 
ming language (Joviai.I. Each line, as it is 
entered, is syntax checked, a feature which 
is representative of a number of time-shar- 
ing system program editors. 

The editing repertoire includes insert, de- 
lete, replace, copy, and move, all applying 
to one or more lines (hut not within finest. 
The fines are numbered and same-length 
substitutions within a line can lie made by 
specifying the fine number, driving the cur- 
sor to the desired point with the space bar, 
and typing the correction in place. The fine 
number is needed because there is no exten- 
sive correlation map between the data 
structure and the screen display. A continu- 
ous input mode (the “compose” mode) also 
exists, in which consecutive lines may he 
inserted without having to specify the insert 
command for each. The program tries to 
minimize user typing and, since it hits been 
designed for a specific language, performs 
immediate syntactical checking, thus con- 
siderably reducing a programmer’s debug- 
ging time. 

Syntax checking can he an important 
function of a program editor. However, 
many systems having this capability can 
support only a limited number of languages 
because the syntax of the language is built 
into the system. If the syntax checking were 
table-driven, however, all that would be re- 
quired to add a new language to the system 
would he a new syntax table. At this time, 
it is not clear to the authors whether the 
time required to perform syntax checking 
on-line at the editing stage is justified when 
the user has at his disposal a fast (possibly 
interactive or incremental) compiler. The 
next system is also syntax driven, but pro- 
vides the user with a new technique for con- 
structing his program. 

Emily, Argonne National Laboratory 

With the other editors described in this 
paper, a user creates his text by typing the 
appropriate strings of characters. With 
Emily [10], he creates and modifies program 
text by selecting among choices presented 
by the system in accordance with a syntac- 


iu;> 

tic description of the programming lan- 
guage. Users interact with the Emily sys- 
tem via an IBM 2250 Graphic Display 1 nil 
attached to a 860. 

Most programming languages can lie de- 
scribed by a syntax, a set of rules specify- 
ing one or more replacement strings for 
each of a set of nonterminal symbols. For 
example, Figure 3 shows it simple syntax for 
;t small pari of FI. I. kite nonterminal 
symbols are those that begin with "s. and 
end with ">”. All nonterminals in the text 
must be replaced before the program is 
completed. The rule for a variable < VAH.- 
specilics entry of an identifier from the key- 
board or from a display of other identifiers 
that have already been entered in the pro- 
gram. 

Text is created with a sequence of selec- 
tions. The screen of the 2250 appears di- 
vided into three ureas: text, menu, and 
message. The text area in the upper two- 
thirds of the screen displays the text under 
construction as a string containing nonter- 
minals. Nonterminals are underlined and 
one is enclosed in a rectangle to mark it as 
“current.” The menu (the lower third of the 
screen) displays a set. of possible replace- 
ments for the current nonterminal. The user 
selects a replacement rule and the system 
makes the substitution, locates a new cur- 
rent nonterminal, and displays a new set of 
choices. The message area is used for entry 
of identifiers and also displays status and 
error messages. 

Creation of an IF statement, might take 
place in the steps shown in Figure 4. The 

<STMT> <VAR> = <EXPR>; 

| IF <EXPR> THEN <STMT> 

| DO; <STMT *> END; 

<STMT*> ::= <STMT> 

| <STMT> <STMT*> 

<EXPR> : : = <EXPR> + <EXPR> 

I <VAR> 

<VAR> is an Id 

Fig. 3. Syntax for small part of PL/I. 
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1) k S TMT > [ 

2) IF |< EX PR >| THEN <STMT> 

3) IF |< VAR > I THEN <STMT> 

l|) IF FIRS T T I M E THEN kSTi-lfTI 

5) IF F I RST_T I ME THEN DO; 

RstmtoI 

END; 


23) IF F I RST_T I M E THEN DO; 

FIRS T_T I M E = FALSE; 

SYMBOLS = NULL; 

END_T I ME = DAYMINUTES + 10; 

END; 

Flo. 4. Sequence of steps to generate un IF state- 
ment. 

initial current nonterminal is <STAIT> 
and the menu would display the three 
choices shown below. 

< VAR > = <EXPR>; 

IF < EXPR > THEN <STMT> 

DO; <STMT*> END; 

The user would point the lightpen at the 
secontl of these, and the system would gen- 
erate the second line of Figure 4. 

The full implemented syntax for PL/I 
has 24 choices for <STMT>, but excludes 
most PL/I input/output features. Other im- 
plemented syntaxes include Gedanken [16], 
a syntax for outlines, and a syntax for 
input to a processor to generate syntax ta- 
bles. The outline syntax has been useful for 
outlining papers and talks. 

A syntax imposes a hierarchical structure 
on text, and this structure is used to advan- 
tage both within the system and in the sys- 
tem facilities available to the user. Each 
selection from the menu generates a node 
with space for one pointer for each nonter- 
minal in the replacement string. When a 
nonterminal is replaced, the corresponding 
space is filled in with a pointer to the node 
generated for the replacement. Each nonter- 
minal thus generates a subtree of nodes that 
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is presented on the display as a string of 
text. 

A user can change his view of the lr\t, so 
the string generated by any nonterminal is 
represented bv a single symbol called a 
"holophrast." For example, the IF state- 
ment could be displayed with all text gener- 
ated from the <STMT*> represented by a 
holophrast. In larger programs, this feature 
means that the user can view the structure 
of his text without viewing the details. Al- 
ternatively, he can cause the display to de- 
scend into the structure and view the de- 
tails in full. 

Text is also modified in terms of its struc- 
ture. The text represented by any holo- 
phrast can be deleted, moved, or copied. 
Modification of the file is made easier by 
allowing a file to contain any number of 
arbitrarily sized, named text fragments (rec- 
ords) such that text, can be moved between 
them. When text is deleted, it is not de- 
stroyed immediately, but is automatically 
moved to a special system fragment called 
“DUMP'. If a mistake is discovered before 
the next text modification is made, the de- 
leted text can be retrieved from this dump. 

The syntactic formalism developed for 
the Emily system has a number of interest- 
ing aspects. Because the system formats the 
display of text for the user, the syntax must 
be specified by the designer with inline for- 
matting codes that specify indentation and 
new line operations. A special notation for 
lists allows arbitrary list separators and fa- 
cilitates user commands to insert and delete 
list elements. Finally, the identifier block 
structure can be specified in the notation, 
and the system offers an interactive cross- 
reference feature. The user can ask to see 
all declarations or all instances of any iden- 
tifier in any given block. As lie pushes a 
button, each instance is displayed in turn. 

User engineering was an important con- 
sideration in the design of Emily. A certain 
unity of appearance is achieved because the 
program text is created, viewed, and modi- 
fied in terms of its structure rather than as 
literal (meaningless) eharacler strings. Text 
expands and contracts from nonterminal to 
string to holophrast and back. The number 
of direct user interaction subroutines was 


kept small mi the User could easily under- 
stand the input conventions. For instance, 
there is only one subroutine that permits 
the User to type a string of text, l >t her tech- 
niques allow menu picking rather than typ- 
ing of codes wherever possible. However, 
Emily's designer reports that preliminary 
experimentation showed the lightpen to lie a 
poor device for menu selection. The user 
must aim his whole hand and arm, and he 
must wait for the system to display the 
choices. There is nothing to aim the pen at 
during this wait. A better device might 
allow it user to select from among twenty or 
thirty choices with one hand, without hav- 
ing to look ill that hand. With such it de- 
vice, it user could make selections as fast as 
possible, even without wailing for the dis- 
play, if he were familiar with the syntax. In 
dealing with syntax with which he was less 
proficient, he could wait to make it selection 
until he hits read the choices. 

A second problem is (hat identifier selec- 
tion is not as easy as selection of syntax 
rules because identifiers are specific to an 
individual program. Emily displays existing 
identifiers for selection, but. their location in 
the menu can change its new identifiers are 
added. 


FREE FORM TEXT EDITORS 

The traditional method of manuscript com- 
position and publishing is a slow, unsatis- 
factory process. Turnaround time and com- 
munications between authors and publishers 
are so poor Unit documents tire often out of 
date before they are published. The au- 
thor's role in the process is perhaps the 
most old-fashioned of all. llis tools include 
a pencil, a typewriter, some pieces of paper, 
tin eraser, a few reference works, and his 
mind. The fussy, professional (and proba- 
bly imperfect) author faces a very real 
problem in that he has to rewrite his manu- 
script many times, do research, and refer to 
previous writings. He cannot store all the 
information he needs in his own mind. He 
would like to try different versions and 
techniques before deciding on the final 
form; he would like to have his previous 


lli.'i 

writings and all his references at his finger- 
tips. In other words, lie needs the power and 
memory of a computer to assist him in his 
creative tasks. Especially to the computet 
scientist as author, it is esthetically pleas- 
ing to utilize the computer in till aspects of 
his work, including writing and document- 
ing as well as programming. 

The most obvious advantage ottered b\ 
computer-assisted editing is the tremendous 
reduction in time required to produce a 
final, or alternate, document. Normal edit- 
ing requires many cycles in which text must 
be read and reread, typed and retyped. Text 
stored in the computer, on the other hand, i- 
never retyped but only updated. As a conse- 
quence, the number of typographical errors 
is reduced and far less proofreading is re- 
quired. Using an on-line editing system, an 
author or editor receives cleaner-looking 
(draft) copy and he receives it more often 
-when he asks for it, not a day or two 
later. Thus, an author can afford to be more 
particular about expressing an idea exactly 
because it is very inexpensive in terms of 
both time and effort to print out an interme- 
diate draft. Furthermore, if the system were 
adapted to handle many users simultane- 
ously, and were available on a full-time ba- 
sis, the user would never need to request any 
intermediate printed copy since all his writ - 
ing and editing could be done on-line. 

In summary, then, the advantages of 
working in this manner include: 

1 1 easy access ; 

21 immediacy of response; 

3) ease of making hard copy without inter- 
mediate stages of typesetting, proof- 
reading, resetting, reproofing, etc.; 

41 reduced "turnaround" time for any type 
of file research and writing task; 

5) common access to the same data base 
(this is useful for a pool of researchers 
or documentors working in the same 
area, or for common access to updated 
(project.) management information); 

6) “constructive plagiarism”: the easy 
modification of previously written mate- 
rials for present purposes (as in the 
writing of papers, contracts, proposals, or 
brochures) ; 

7) great simplification of document dissemi- 
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nation and storage — no hard-copy bulk, 
but any degree of archival protection 
desired ; 

8) far greater flexibility for browsing and 
linking text fragments than with manual 
methods of working with hard cojiy ; and 
01 relatively modest cost for all this in- 
crease in activity and cliicieney, when 
compared with all aspects of present 
systems: writing delay, retyping, proof- 
reading, typesetting, revision of galley 
and page proof, printing, binding, distri- 
bution, storage land subsequent inacces- 
sibility due to distance, lack of shelf 
space, poor indexing, borrowed or lost 
copies, etc.). The user cost includes the 
machine time used (typically a 5% or 
smaller rate of CPU utilization/user 
time) and the rental or purchase cost of 
the terminals employed. 

One of the disadvantages of on-line edit- 
ing compared to hard-copy editing is the 
expense; terminals, and especially commu- 
nications, are still too costly, although 
prices, particularly of terminals, are coming 
down rapidly. Also, the convenience and 
naturalness of hard copy are still important 
to the “back of an old envelope” school of 
writing and the “5:07 Stamford express/red 
pencil” school of editing. Finally, there is 
the inability to store a record of all the 
editing changes made (important to maga- 
zine publishers, for instance). Because of 
these disadvantages, the transition from 
hard-copy to soft-copy techniques will bo a 
gradual one and will require greater cost 
effectiveness, reliability, and system availa- 
bility than is obtainable with current hard- 
ware and software technology. Also, the 
considerable problem of economically re- 
taining an “edit trail” record of changes to 
a text is still only in the research stage [8]. 

The systems described below are represen- 
tative of the current state of the art, and 
range in cost and capability from limited to 
extremely high. Most of them are not avail- 
able as a service on the open market, being 
supplied either as part of a time-sharing 
operating system for those few lucky 
enough to have access to one, or existing as 
a limited access (university) research proj- 
ect. Those discussed first are in many sen- 
ses less powerful than the sophisticated 
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time-sharing system program editors. They 
are discussed in this section on text editors 
because tln-y are usually marketed as such, 
and are available on medium-priced com- 
puters (without hardware address transla- 
tion I, thereby allowing minimal editing at 
minimal cost. For example, ATS will run in 
ill K bytes of an ordinary batch processing 
3(>0 and service several dozen terminals. 
The systems mentioned last (11 1: Press 
and NFS) are far more powerful, occupy 
significantly more core (as much as 100- 
200K bytes of cure re.-idenc , and perhaps 
several times that much for the entire sys- 
tem), and represent many man-years of de- 
sign and implementation effort. Also, they 
are not subject to most of the bothersome re- 
strictions imposed by line orientations of 
the previous systems. 

Magnetic Tape Selectric Typewriter 
(MTST), IBM Corporation, and 
ASTROTYPE, Information Control Systems 

These two extremely rudimentary 
“stand-alone" editing systems are similar in 
their design and intended use, and do not 
require the services of a large general-pur- 
pose computer. MTST [ 13] consists of a sin- 
gle IBM Selectric Typewriter connected to 
a small control/memory unit and is used for 
printing out neat looking (Imt unjustified) 
form letters and manuscripts (c.g., legal 
contracts). The Astrotyi>e system [1] con- 
sists of up to four typewriters and memory 
units connected to one control unit (the 
DEC PDP-8) and, in addition to preparing 
forms, is used for preparing input for pho- 
to-composition devices. These systems were 
not designed for massive editing jobs. The 
only editing allowed in MTST is to substi- 
tute equal length character strings; to effect 
a substitution of a larger for a smaller 
string, the entire manuscript with the 
correction must be copied onto a second 
tape. The correct place for an edit is located 
by printing out the contents of the. tape 
until the area of the edit is approached; the 
operator must then manually stop the proc- 
essor and retype the line. 

In both systems, the text is recorded on 
magnetic tape as it is typed in, and can 
later be modified and printed in final form. 
Text can be typed in an “unchangeable” 


mode, in which case it is printed exactly as 
it was typed, or in an "adjustable” mode, in 
which case the control unit prints blocks of 
text (e.g., paragraphs I according to tin' cur- 
rent column width (which can vary). 

, 'The editing functions of Astro rveK are a 

bit more reasonable than (hose of M IST. 
Text is stored in lines, which are numbered 
sequentially from the top of the tile. These 
relative numbers naturally change as new 
lines are inserted or old tines deleted. The 
basic editing command is substitute. Substi- 
tutions within a line are made by typing 
the line number, the old character string 
(plus any additional context that might be 
required to uniquely identify the text I, and 
the new string (including the additional 
context used above, if applicable). As in the 

, CMS editor, insertions and deletions within 
a line are degenerate forms of substitution. 
Thus, to insert within a line, one must spec- 
ify context to the left, or right of the inser- 
tion point as the old string and repeat this 
context plus the text for insertion as the 
new string; to delete within a line, the text 
to be deleted must be typed as the old 
string, and null text specified as the new 
string. However, there is still the restriction 
that editing changes must be fairly local 
because the line number and old and new 
strings must, be typed on the same type- 
writer line. Individual lines may also be 
erased and moved by number. Verification 
is provided by a printout of the line before 
the change is actually made. 

Printing in both systems is done at the 
typewriter at the rate of 150 words/minute, 
anil various fonts and type sizes may be 
used by changing the typing ball. The 
printing can also be programmed to stop in 
the middle, so that additional input may be 
entered manually, and then continue. This 
is especially useful when changing a portion 
of a form letter. 


sitiou output, was available until recent 1> 
on a dial-up, service-bureau basis. They an 
closer to a reasonable editing system than 
either MTST or Astuutyi’K, allowing un- 
ions forms of input and formatted output, 
and providing a larger set of editing and 
lormatling coninmnds. Except for the pho- 
to-composition output of VJIVom, they are 
more primitive than the CMS context edi- 
tor, lacking, for example, pattern-scanning 
facilities. 

As in Astrotyck, each time a line is 
typed in, an internal line is created and a 
line number assigned. The length of an in- 
ternal line may vary from 0 to 130 charac- 
ters, and a text file may contain up to 9999 
internal lines in a linkcd-li.-t storage struc- 
ture similar to that of the CMS editor. The 
line numbers, as in Astro n in:, are relative 
to the top of the tile and change dynami- 
cally as lines are inserted or deleted. This 
can be confusing because the line numbers 
of text strings to be edited may no longer 
correspond to those of the most recent 
printed copy. The designers of ATS suggest 
that editing be performed from the bottom 
of the file to the top; this eliminates the 
problem of changing line numbers, but is 
not a natural way of working. 

Deletions of one or more lines are quite 
easily made, but to insert new lines in the 
middle of a file, the lines must first be 
typed at the end of the file and then moved 
to the desired position. Text can be moved 
around by lines, but not. copied. Substitu- 
tions, deletions, and insertions within a line 
are made as in Asthotype. 

Text can be entered in “formatted” mode, 
in which case the text can be arranged by 
the output program to satisfy the specified 
page format (e.g., line justification), or in 
"unformatted” mode, in which text is saved 
and printed exactly as it was typed in (use- 
ful for rigidly formatted material such its 
tables). As in the two systems just de- 
scribed, an on-line printout can be stopped 
in the middle, allowing the user to type in 
additional text. 

Systems such as these are. far from ideal 
for general purpose editing. The terminals 
used, however, arc inexpensive compared to 
CRT displays, and the service required 
from the CPU is minimal because the edit- 
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System/360 Administrative Terminal System, 
IBM Corporation, and VIPCOM, VIP Systems 
ATS [19] and VIPcom [24] are very simi- 
lar commercial editing programs that utilize 
the IBM 2741 typewriters as the interactive 
device. ATS is provided by IBM as a 
standard package on the 300 series while 
VIPcom, basically ATS with photo-eompo- 
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ing functions are few and the data structure 
quite uncomplicated. 

A Tablet-Based Editor, 

Carnegie-Mellon University 

This experimental editor [4] uses hand- 
drawn proofreader's symbols as the method 
of editing text displayed on a CRT. The 
symbols are drawn on a Hand data tablet 
and are recognized by the program by pass- 
ing various characteristics of a given symbol 
through a decision tree (discrimination 
net). The editing actions recognized include 
insert, delete, substitute, interchange, move, 
and scroll. Since this experimental system 
was not meant for production editing, there 
arc no real paging and file-handling mecha- 
nisms, nor are there any hard-copy output 
facilities. 

The editing functions are specified in a 
very natural manner. As an example of how 
this type of editing is performed, consider 
the substitute function. The user draws a 
line through the text to be deleted. The sys- 
tem deletes this line, blinks the indicated 
text for verification, separates the text by 
opening a blank line, and inserts a cursor, 
enabling new text to be typed in from the 
keyboard. 

The conclusions reached by the experi- 
menters were: I) that using such a system, 
vocal input of text could be practical, even 
with high error rates, because any errors are 
easily corrected; and 2) that a self-suffi- 
cient editing terminal requiring computer 
intervention only to “fetch, format, and 
store text” could be constructed, because 
the decision tree and primitive editing logic 
could be made part of tbe terminal’s hard- 
ware. However, the cost either in CPU util- 
ization for on-line recognition or in hard- 
ware development makes this form of edit- 
ing impractical at present. 

The Hypertext Editing System (Hes) and 
File Retrieval and Editing SyStem (FreSS), 

Brown University 

The Hypertext Editing System [3] is a 
flexible, CRT-based (IBM 2250) system al- 
lowing full editing and formatting capabili- 
ties. It is oriented toward “typeset” output 
(using a computer line printer) as well as 
flexible input and on-line editing. A light- 
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pen and a set of "function keys,” under pro- 
gram control, are used to indicate to the 
system the nature of the edit to be per- 
formed. The editing function is selected by 
pressing the appropriately labeled function 
key. The portion fa) of text to which the 
function applies arc then indicated by 
pointing at the text with the lightpen. No 
command codes for the functions need be 
remembered, and no extra typing is re- 
quired to indicate a context string. 

To delete a portion of the text, the "de- 
lete” function key is pressed, alter which 
the two endpoints of the text to be deleted 
are pointed at with the lightpen. The inclu- 
sive text is then blanked out on the display 
for verification. If the deletion is correct, it 
is "accepted” by pressing a control key; 
otherwise it may be "canceled,” leaving the 
original text intact. Among the editing 
functions are insert, delete, substitute, rear- 
range, and copy. The system provides 
prompting messages that specify the actions 
available at each step. Large strings of text 
may be edited in one command, although 
certain implementation restrictions have 
been imposed. For example, a maximum of 
approximately 2500 characters may be de- 
leted or rearranged at a time (but major 
restructuring of text may be done by creat- 
ing new "branches” between text fragments, 
as explained below). 

In addition, many formatting options are 
available so that text, may be formatted 
both for on-line display and hard-copy 
printouts. An off-line computer typesetting 
program, IBM’s Text 300 program [21], is 
used for final hard-copy printing on a com- 
puter line printer equipped with an upper 
and lower case print chain. 

The data structure, and hence the editing 
operations are entirely independent of dis- 
play or printout lines and pages. Text is ex- 
ternally segmented by the user into arbitrar- 
ily long user-designated fragments called 
“text areas” (see Figure 51. Each area is a 
continuous linear string of text, like an 
Egyptian scroll, and might be a chapter, an 
entire book, or a short footnote. These areas 
may be interlinked and cross-referenced in 
any manner so as to form a directed graph 
of text segments (the vertices of the graph) 
and their cross references (the edges). Two 


types of cross references exist : "branches ’ 
are unconditional jumps between two frag- 
ments that the user may encounter in the 
text t typically in a "meiin"l and which 
force him to lightpen a choice in order to 
proceed, while "links" are conditional 
jumps, which the reader may bypass or 
lightpen. The link, in idled . is an on-line 
generalization of the manuscript footnote 
principle that invites digressions, ancillary 
explanations, and browsing. 

The resultant mobile of text tragnieiits is 
called a hypertext, "the combination of na- 
tural language text with the computer’s ca- 
pacities for interactive, branching, or dy- 
namic display ... a nonlinear text . . . which 
cannot be printed conveniently • • . on a con- 
ventional page . . ." ( 1 T J. A practical example 
of a hypertext might be an on-line encyclo- 
pedia or a set, of programming and systems 
reference manuals, with each cross-reference 
lightpen sensitive. Functions are provided 
that, allow the fragments of text to be inter- 
preted and examined in a variety of ways, in 
particular to have linear paths traced 
through the hypertext, either for on-line 
browsing purposes or for printing in a con- 
ventional manuscript form. The system also 
remembers the sequences of branches or links 
that the reader has taken, and this allows 
him to reverse his trail. Random access to 
any point in the text is provided by allowing 
the author to assign “labels” anywhere in the 
text and later to “jump" to any of them by 
lightpenning the appropriate one from an 
alphabetized menu. 

A given area of a hypertext is stored in- 
ternally as one or more pairs of variable- 
sized “pages” (unrelated to a printed page), 
each pair consisting of an “order code” page 
and a “text” page. The order code page is 
an ordered sequence of text pointers (dis- 
placements into the text page) interspersed 
with formatting and structure codes, while 
the text page contains the actual literal 
strings of characters. To accomplish an edit, 
order codes and their pointers are inserted, 
deleted, or updated while the text strings 
remain intact. An edit therefore involves 
little character shuffling, at the expense of 
rapidly accumulating “garbage” strings. 

Although Hes is in production use in a 
number of 2250 installations for the writ- 
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l’u;. 5. Model of ;i simple Hypertext. 

ing of manuals, theses, and proposals, it wa 
essentially an experimental system lor stud 
ying text handling techniques as well as up 
plications of hypertext as a new medium 
Fress [23] is a commercially available 
production version of the system I lor tin 
360/67 as well as the standard 3601 sup 
porting a spectrum of terminals in such a 
way that all functions are available even oi 
the lowest power terminal. 

The standard terminal is a 2711 type 
writer, best used for initial input and mint), 
editing of small files; it is also used as at 
acoustically coupled remote terminal am 
for remote hard copy. Also supported is tin 
IBM 2260 CRT alphanumeric display (am 
its equivalents), used for faster and mur. 
convenient editing and on-line browsing 
More powerful CRTs operate as in Hes, am 
arc intended for major restructuring am 
rapid editing (rush jolts). New types of ter 
minals can be supported by simply includ 
ing a new program module to handle de 
vice-dependent input and output, and 0 
convert editing requests into their standan 
internal representation. 

Facilities not in Hes but implemented ii 
Fress include completely arbitrary siz. 
string edits, pattern scanning, keyword re 
trieval, photo-composition output, interfil 
linking and editing, and protection of file 
and blocks of text by passwords that cai 
have a mask enabling or disabling each o 
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the hundred-odd commands individually. 
Section outline facilities, similar to those 
described in the section on NLS, are cur- 
rently being debugged. As an example of 
string editing on a 2741, a substitution 
(“change”) of the string “New sentence" 
for a large sentence that starts with the 
string “Tlu; text...” and ends with “end" 
could be specified as 

c/Thu l . . . cnd/New sentence 

where the “/" again denotes an arbitrary 
delimiter and the ellipsis is a pattern that 
matches all characters between the initial 
"t” of “text” and the first occurrence of 
“end”. 

Unlike the separate text page/order code 
page data structure of IIes, the data struc- 
ture for Fress is a set of arbitrarily long, 
continuous (but naturally internally paged) 
strings of text with “order codes” (which 
indicate formatting and structure) directly 
embedded within the text. Editing is done 
by operating directly on the character 
strings, thereby causing considerable mov- 
ing of characters (spreading them apart for 
an insert or closing them up for a delete) 
but avoiding the rapid buildup of garbage 
strings that occurs in Hes. Additionally, ta- 
bles of pointers are used to identify impor- 
tant internal places in the strings, such as 
those that “anchor” labels or cross-refer- 
encing links. 

NLS, Augmented Human Intellect Research 
Center, Stanford Research Institute 

The work being done by the AHI group 
at Stanford University is most impressive. 
Their system (NLS) embodies much more 
than just a text editor; their aim is to pro- 
vide a new way of thinking and working by 
utilizing the power of the computer in all 
aspects of one’s work [9], 

We are concentrating fully upon 
reaching the point where we can do all 
of our work on line — placing in com- 
puter store all of our specifications, 
plans, designs, programs, documenta- 
tion, reports, memos, bibliography and 
reference notes, etc., and doing all of 
our scratch work, planning, designing, 
debugging, etc., and a good deal of our 


intercommunication, via the consoles 

191 - 

In this survey it is not possible to de- 
scribe adequately the many features of this 
powerful system; the All 1 paper [9] is 
highly recommended. Currently, the Center 
hits a time-shared S1)S 940 ((55 Iv, 24 bit 
curd with a 4.5 megabyte swapping drum 
and a 9li megabyte file storage disk. At the 
time this |mper was written, the facility 
was being upgraded to a I’Dl’-lO configura- 
tion, in conjunction with the NLS center 
becoming the information utility for the 
AHl’A network ( 18], handling all its docu- 
mentation, archival storage, and informa- 
tion dissemination. The 910 system, while 
capable of handling teletypes, is primarily 
dedicated to twelve “work stations.” These 
are standard television monitors, displaying 
the output of small CHI's, and equipped 
with a "mouse” for pointing to text and a 
one-hand live-key handset for specifying 
commands to the system. The handset can 
also be used to input text, although a stand- 
ard keyboard is provided. 

Of particular significance is the ability of 
NLS to display a file from many different 
points of view. For example, the hierarchi- 
cal outline structure of a text — the various 
headings — may be stored as part of the 
data structure, and one may ask to see, for 
example, only section 3.1.4, or all sections 
down to two levels of subsectioning, or the 
first line in each of the subsections on the 
fourth level. The text is thus viewed as a 
collection of sections (called “statements”) 
with a tree structure superimposed on this 
basic data structure. Each statement (less 
than 3000 characters) is meant to contain a 
single complete thought or idea, but may 
have substatements down to an arbitrary 
number of levels (see Figure 0). Most 
standard tree manipulations are allowed at 
a given level in the tree; o.g., locating or 
deleting the next node or the previous one, 
locating the first subnode, rearranging 
neighboring nodes, etc. Note that this hier- 
archical approach to files, in contrast to the 
continuous string approach of Hes and 
Fress, is useful for documents as well as 
programs. 

Many ways of viewing the text exist (de- 
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Each node is a text section 01 statement. Thu doited connections 
represent optional cross references and associations between 
statements (links). 

Fit;, (i. I lit •rarcliiral slal<*itu*ikl >1 1 uuluiv of NLS. 

termined by “viewspccs,” o.g., displaying 
only the first “n” levels of the tree or the 
first “n” characters of each statement) and 
elaborate methods for jumping around in 
the text are available (by complex pattern 
searches, by the statement outline structure, 
keyword retrieval, etc.). Cross references, 
similar to Hes/Fhess links, may be made 
between statements in the hierarchy. 

The editing commands are extensive and 
specialized, o.g., insert character, insert 
word, and insert statement are all separate 
commands. Most editing is done on a state- 
ment basis so that one cannot, in one opera- 
tion, substitute for a string that crosses 
statement boundaries. One can, however, 
move part of a statement into another. Ed- 
iting within a statement is done by copying 
the updated literal character string to an 
available place in an internal page. Since 
the text is hierarchically arranged, rear- 
rangements of the tree structure on a state- 
ment basis (causing automatic renumber- 
ing) are easily and economically made; the 
statement hierarchy is encoded by explicit 
pointers to the pages on which the individ- 
ual statements are stored, so that only 
pointers, not text, need be moved. 

Statements may contain such embedded 
control codes as font changes, keywords 


(attributes), user names (labels), rlo.-s ret 
c relives to other statements', etc.; tln-.-i- 
codes are contained inside syntactic delimi- 
ters (e.g., brackets) within the statement 
text. They call therefore be treated as ol'di 
nary editable text until their special pur 
pose is invoked by a command, and thi. 
allows the knowledgeable user to modify 01 
ders using ordinary text -editing command 
rather than Inning to invoke speciali/.ed 
"change order" commands. I’ASS l in Ml..- 
provides hard-copy formatted output for a 
variety of devices, such as the line printei 


EDITING FEATURES OF TYPICAL TERMINALS 

The most common editing terminal today i.- 
still the teletypewriter (Teletype model 
ASK33 or IBM 2741 and their equivalents! 
principally because of their relatively mod 
esl cost - $800 for the simplest, teletype to 
approximately $3,500 for the 2741. In par- 
ticular, acoustically euupled teletypewriters 
running up to 300 baud ( 15- 30 characters 
second) provide a convenient, portable ter- 
minal for original input, program editing, 
and “minor surgery” on ordinary manu- 
scripts. For free-form, general-purpose text 
editing, however, the teletypewriter's ad- 
vantages of low cost and hard copy tran- 
scripts are outweighed by the disadvantage 
of slow and noisy "display.” An alphanu- 
meric CRT display, capable of rapid dis- 
play of many hundreds of characters and 
local editing facilities is almost essential. 

The price of such alphanumeric terminals 
has decreased steadily over the last several 
years, while the available capabilities, in 
terms of number of displayable character, - 
and editing options, have increased. A con- 
tinuum of editing power is available in 
these terminals, starting from a small CUT 
(selling for as little as $2,000) to replace 
the hard-copy teletype and ranging to a 
$15,000 large-screen terminal that is capa- 
ble of local interactive text editing. Below 
are several examples intended to give the 
reader an idea of the cost/powcr combina- 
tions that are available along the spectrum. 
(The teletype replacements have not been 
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considered, because they have no editing 
cuj labilities to speak of.) 

The IBM 2260/1 is a simple buffered 
CRT capable of displaying 960 characters 
(12 lines with 80 characters each) from a 64 
symbol character set. Cursor manipulation 
using up/ down/left/right/newlinc controls 
is supplied to assist in the two functions 
available, which are character input, and 
character overstrike (the only real editing 
capability). In single CRT quantities, the 
2260 is prohibitively expensive, as it re- 
quires a buffer/display controller — the IBM 
2848/3. However, since one 2848, 3 can con- 
trol up to eight 2260/1 CRTs, the equip- 
ment, if used in quantity, can be cost effec- 
tive, renting at approximately $150/termi- 
nal/month. 

The Computer-t 'plies CO: 70 is a more 
sophisticated device for text editing than 
the 2260. Basic cursor controls of up/ 
down/left/right are enhanced by the repeat 
function, which facilitates rapid cursor po- 
sitioning. Hardware editing capabilities — 
character and line insert and delete and 
character overstrike — are available in a 
system that sells for approximately $8,500. 
The terminal may be used stand-alone to 
edit text stored on magnetic tape, or may 
access data bases on a mainframe computer 
over low-speed communication lines. Addi- 
tionally, the ability to display 3000 charac- 
ters from an 88 symbol ASCII character 
set, which includes upper and lower case, 
make the CO: 70 more useful as a text, 
rather than program, editing terminal. 

The Computek model 100 is a micropro- 
grammable terminal capable of displaying 
1000 upper and lower case characters, with 
the potential of doing nontrivial editing lo- 
cally. It can be specially microprogrammed 
to edit a database stored on a cassette or 
other local memory, without using the re- 
sources of a mainframe computer. The basic 
firmware supplied with the system provides 
character, word, and line insert and delete 
for approximately $4,500, with possibilities 
for expanding Read Only Memory to han- 
dle more complex functions, in the Compu- 
tek, high speed is sacrificed in favor of low 
cost. Use of relatively slow, but inexpensive 
delay-line memory causes reduced editing 
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sliced as the complexity of the required 
functions increases. For example, $5,000 is 
sufficient to purchase a Model 100 capable 
of performing a rearrange in addition to the 
standard functions listed above, but the re- 
sponse time for a simple rearrange may be 
oil the order of seconds! Because of the 
local editing ability, useful work can lie ac- 
complished with the terminal attached to a 
general-purpose computer over low capac- 
ity telephone lines. 

The Harris 1100 is similar to but. more 
powerful land expensive) than the Compu- 
tek 100. The basic system consists of a 2000 
character CRT (with single and double col- 
umn formats), 2K bytes of M( )S shift, regis- 
ter memory, a 100-symbol character set, 
and keyboard and function keys; it sells for 
$14,500. Display buffer memory is expanda- 
ble in 2K byte increments, to a maximum of 
OK bytes, at. a cost, of $2,000 per increment 
to provide buffering of and scrolling 
through a 6000-character data base. Editing 
may be accomplished on-line via telephone 
communications lines with capacities up to 
1200 characters per second, or off-line, using 
paper tape for all I/O. Standard features 
include a cursor with up/down/left./ right/ 
newline/home controls (and, unfortunately, 
no repeat key), a scroll function that is de- 
signed for systems with more than 2K bytes 
of memory, and a nice range of editing 
capabilities. In addition to the standard 
character editing functions of insert, delete, 
and overstrike, these include “block” editing 
commands: by inserting special “define 
block” symbols in front of and immediately 
following an arbitrary string of text, a block 
may be defined and then edited (either de- 
leted or rearranged — moved to the current 
cursor position) or output (either to paper 
tape or a computer, depending on the mode of 
operation). The terminal is oriented towards 
copy editing, and is used by a number of 
newspapers and printers in the United 
States and Europe. 

Those types of terminals, with no local 
writable memory other than the display 
buffer, are excellent tools for editing simple 
linear text, but lose much of their usefulness 
when being used on a data base that is not 
pure text or is not stored in screen image 


format. For example, if the text contains 
typesetting codes such as skip lines, indent, 
etc., whose effect is to be shown on the 
screen, a translation must be made between 
the internal data structure and the external 
appearance of the text, and vice versa. 
More seriously, cheeks must be made to 
prevent the editing ol nonexistent blanks 
(those skipped by a paragraph, for exam- 
ple) or typesetting codes that have global 
scope in the text, (e.g., indent). If, therefore, 
the computer cannot just place the updated 
text back into the data base, then it must be 
apprised of the changes made on the screen 
by the terminal (to check them lor validity 
and then to execute them). 4 he terminal 
must either transmit the changes made to 
the displayed text operation by operation, 
or the program in the mainframe must let 
local editing take place for a while, and 
then interrogate the resultant local buffer. 
The mainframe program must then com- 
pare (display buffer to display buffer) what 
was sent, to the terminal with what came 
back, decompiling the commands from the 
modified display buffer to check and modify 
the data base. The first process is expensive 
in input/output and the second in CPU 
usage. 

An answer to the problem of handling 
structured or formatted (ext could be to 
transmit, a section of the structured data 
base to a remote terminal and have it lo- 
cally modify the data base with its own 
(primitive) data-structure editing routines, 
transmitting the updated data base back to 
the mainframe on a batch basis. To accom- 
plish this task, local computation and 
read/write storage are required in addition 
to the display buffer. 

The I mi. AC PDS-l, an example of a de- 
vice capable of local data-structure editing, 
is a small computer with up to 32K 16 bit 
words of local memory. If is integrated with 
a CRT that uses the l’DS-1 core for a dis- 
play buffer. It has no character generator, 
and characters are displayed through the 
use of character-stroke subroutines, exe- 
cuted by the scope. Cursor manipulation is 
handled by software in the PDS-l. Rudi- 
mentary vector graphics are also provided, 
and the total package (with 4Ix bytes of 
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core and a lightpeni can be obtained lor 
approximately $ 1 0,001). 

CONCLUSION 

Un-line composition and editing ol pro- 
grams, coupled with interactive debugging, 
lias become an established, cost-effective 
use of computers. Similarly, minor text ed 
iting, sin’ll as the correction ol typographi- 
cal errors in memoranda, is cost effective, 
since only teletypewriter consoles and mini- 
mal service from the CPU are required. In 
contrast, the imaginative use of computers 
for on-line composition and extensive ma- 
nipulation of free-lorm text is still in the 
early stages of experimentation and user 
conversion. This is due partially to the high 
cost of CRT terminals that provide the 
human factors essential to general purpose 
editing, partially to the high cost ol system 
resources and implementation time for the 
sophisticated programs required, and par- 
tially to the long time required to wean 
users from traditional off-line hard-copy 
processes. 

Hardware prices are coming down stead- 
ily, however, and as more users switch to 
on-line thinking, creating, and manipulat- 
ing, this use of computers will become in- 
creasingly accepted land judged cost effec- 
tive), hopefully to the same extent that nu- 
merical and data processing applications 
are already considered to be a legitimate 
use of the computer. 


POSTSCRIPT 

As a matter of interest., it may be noted 
that the authors wrote and edited this paper 
using several text-editing systems. The 
paper was originally composed on-line by 
“scissoring” and modifying co-author Rice’s 
Master’s Thesis and several other docu- 
ments, using the lightpen of the 2250 display 
console of the Hypertext Editing System. 
The hard copy of this first draff was then 
reviewed by a number of workers in the 
text-editing field. Subsequently the file was 
converted to a Fuess file when Hus was 
phased out, and then edited some half dozen 
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limes on the 2741 typewriter pine to econ- 
omy measures, the 2250 and 22tl0s had “re- 
cessed” in the meantime). 

Tlie final manuscript was reviewed by 
Wilfred J. Hansen, of Argouue National 
Laboratories. In order to save time and to 
meet the publication deadline, his rewrites 
of the Tvedit and Emily sections were 
typed into Argonne’s text-editing system 
and printed out on a dial-up 2741 at Brown 
University. Compromise wording was ar- 
rived at by telephone the same day. Unfor- 
tunately, such long distance cooperation 
with computer intermediary is still primi- 
tive; for example, due to file incompatibil- 
uv the rewrite had to be re-keystroked into 
I hess, Brown’s text editor. Furthermore, the 
' n lire paper had to be re-keystroked in order 
i" be phototypeset. In the future, we may 
L' pe that such duplication of effort will dis- 
appear, and that files can be cooperatively 
.corked on in real-time, regardless of geo- 
graphic location or editing system, and still 
;u reasonable costs. 
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Ten Mini- Languages: 

A Study of Topical Issues in Programming Languages 

HENRY F. LEDGARD 1 ' 
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Tin- pr.ilir.'r.'il imi i>l |ii'.i.ni-:iiiimiu^ huiatiiiaes Inn. misi-d ninny issues uf kiuyiuiye 
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iiiiplriiianl al ion nr fiirma I dalinitiun. 
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data si ruul tiros, iii|iul/uuipiit 
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GENERAL CONSIDERATIONS 

Since the birth of Koktkan, the notion of 
higher-level imigrannning languages lias led 
to a proliferation of speeial- and general- 
purpose programming languages. If seems 
wise, at this juncture, to examine critical 
issues raised by the myriad of languages and 
to try to isolate certain important features 
that seem common to many programming 
languages. In Ibis endeavor, we have pre- 
pared ten mini-languages, each presenting 
in capsule form one or two features taken 
from existing programming languages. (The 
reader may find the work of Strachey [Hi] 
useful as a companion lo I his paper, as he 
considers many issues related to those pre- 
sented here.) 

The issues treated in this paper are sum- 
marized in Table I. Each mini-language is a 

* The work reported herein was performed in 
huge part, at, t lie Programming Research Group, 
Computing Laboratory, Oxford University, Ox- 
ford, England. 


complete (although restricted) language in 
itself, and each is described only informally. 
A modest appeal is made to the reader’s 
knowledge of constructs in existing pro- 
gramming languages. None of the mini- 
languages are exact, subsets of existing 
languages, although much of I lie notation 
and semantic material resembles portions of 
existing languages. Many important fea- 
tures of existing languages are omitted. 
These features include parallel computation, 
interrupts and events in real-lime, file and 
storage management, and simulation. 

The format for presenting each mini- 
language is as follows: 

1) a brief introduction to some topic in 
programming languages; 

2) a description in English of a mini- 
language covering the topic; 

3) several example programs in the mini- 
language; and 

4) a discussion of the mini-language and 
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